Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-004

Text File | 1995-12-31 | 54KB | 1,321 lines

Received-Date: Tue, 15 Mar 1994 16:31:08 +0100
From: [e-mail] (Francois Pottier)
Subject: C.S.M.P. Digest, Issue 3.004
To: [e-mail]
Date: Tue, 15 Mar 94 16:31:03 MET
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 5

C.S.M.P. Digest             Tue, 15 Mar 94       Volume 3 : Issue 4

Today's Topics:

        Code optimization
        Getting Started with TCL
        How would you write a text-based log window?
        Reducing screen flicker in simple animation.
        What to say when the appropiate Gestalts aren't there?
        small snag



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Alex Metcalf)
Subject: Code optimization
Date: Sun, 27 Feb 1994 23:49:17 GMT
Organization: Demon Internet


        I'm working on an arcade game which, when being played, goes
through a "loop" of code every 2 ticks. In this time, it's calling various
functions, doind some calculations, then copying graphics to the screen.

        Since it's only just keeping up on my LC475 (!), I need to optimise
my code so that it works comfortably on 68030 Macs. I want to find out how
long each function call in my loop is taking, but obviously, checking the
ticks won't work. A resolution of time such as 10ths of a tick would be
useful. I can see that I'm going to have to use the Time manager (is that
what it's called?), but I get the impression that it will be more work than
it's worth to implement.

        If this task proves hard, could someone give me some suggestions as
to how I could improve the following operations?

% Copying 24 x 24 pixel graphics to the window (using CopyBits and
CopyMask)
% Dividing numbers (I'm using, e.g. bigNum/littleNum)
% Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits /
CopyMask).

        I'd like faster routines, if possible, but I don't want them if it
means compromising compatibility with other (or future) Macs. That'll be
the day.. :-)

        Thanks,



        Alex

--
Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler

Internet, AOL, BIX:     [e-mail]
AppleLink:              [e-mail]@internet#
CompuServe:             INTERNET:[e-mail]
Delphi:                 [e-mail]@inet#
FirstClass:             [e-mail],Internet
Fax (UK):               (0570) 45636
Fax (US / Canada):      011 44 570 45636

+++++++++++++++++++++++++++

>From [e-mail] (Eric Johnson)
Date: Mon, 28 Feb 1994 00:57:33 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Alex Metcalf ([e-mail]) wrote:

> If this task proves hard, could someone give me some suggestions as
> to how I could improve the following operations?

> Copying 24 x 24 pixel graphics to the window (using CopyBits and
> CopyMask)
> Dividing numbers (I'm using, e.g. bigNum/littleNum)
> Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits /
> CopyMask).

I wrote my own CopyBits for a game that I was writing.  I can dig it
out and post it here.  I can give you the following suggestions
though.

If you've created your icons with ResEdit, you should load them into a
gWorld whose color table is the same one that you will eventually
display your icons.  This will speed up the process because you will
not have to worry about "recoloring" your icons into the new table.
Consider this gWorld your palette of icons from which you will copy.

Then, you need to roll your own CopyBits.  You can optimize the hell
out of this by creating a loop that uses a nice Motorola 680x0
instruction that will decrease a data register, and branch if the data
register is still not zero.  Its a good instruction to use, because it
assumes that the jump will occur, and not flush the pipeline.  I'll be
damned if I can remember the exact name of this instruction.  It
starts with a d, I think.  Sorry, I just can't remember.  If you don't
have a  Motorola 68030 or 68040 book, now is the time to get one.

You should construct the loop so that it will fill up the instruction
cache, or at least use most of it.  That way, when the first run
through of the loop occurs, the code will find its way into the
instruction cache.  On the second run of the loop, its all in the
cache so it runs like a champ.

You might also get better performance in your loop by reading in as
much data as you can into the data registers.  Then, write it to the
destination buffer in one swoop.  I think this might help a touch
because you should be able to maximize the performance of the data
registers.

There are some other optimizations that I made, but I don't remember.
I'll have to dig out that code for you.  It was pretty damn fast.  It
should be a bit faster for you, because you shouldn't need any
masking.  I suppose others might find it useful too, so I'll get
around to posting it.  My only request is that I get credit in
someone's about box.

-Eric
--
Eric E Johnson
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 28 Feb 94 17:12:02 GMT
Organization: PowerTools, Austin, Texas

In article <[e-mail]> [e-mail] (Alex Metcalf) writes:

>I can see that I'm going to have to use the Time manager (is that
>what it's called?), but I get the impression that it will be more work than
>it's worth to implement.

Actually, it's not difficult. Set up a Time Manager task that calls
back every millisecond, and have the task increment a field in your
(extended) Time Manager record. Look at this field before and after
your function call. The difference is how long the function took to
execute.

>% Copying 24 x 24 pixel graphics to the window (using CopyBits and
>CopyMask)
>% Dividing numbers (I'm using, e.g. bigNum/littleNum)
>% Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits /
>CopyMask).

If I recall correctly, CopyBits with a mask region is substantially
faster than CopyMask. But you should try to set up your copying
such only the final copy is offscreen-to-onscreen, and this copy
can be made with a call to CopyBits in srcCopy mode. Then, for
your offscreen-to-offscreen copying, you can write your own masked
copy routine optimized for 24X24 graphics.

                    --Al Evans--
--

Al Evans                         Tu causes, tu causes
[e-mail]               C'est tout ce que tu sais faire
cs.utexas.edu!crucible!al                     -- LaVerdure

---------------------------

>From [e-mail] (Darick DeHart)
Subject: Getting Started with TCL
Date: Mon, 28 Feb 1994 14:49:56 GMT
Organization: RSB/NIH

I have been struggling with Think Class Library for about a week.  I am a
good C programmer with some experience in both Macintosh and Object
Oriented programming.  I am hoping that mastering TCL will allow me to
quickly develop simple Macintosh Applications.

Are there any books (besides the Symantec TCL Guide) that provide "Getting
Started" type information.

I'm also interested in people's opinions on TCL.  Is learning it worth the
investment in time?  How long does it take to become comfortable with the
library?

+++++++++++++++++++++++++++

>From [e-mail] (Brendan F. Murphy)
Date: 28 Feb 1994 18:58:15 GMT
Organization: Motorola Cellular

In article <[e-mail]>, you write:
|> I have been struggling with Think Class Library for about a week.  I am a
|> good C programmer with some experience in both Macintosh and Object
|> Oriented programming.  I am hoping that mastering TCL will allow me to
|> quickly develop simple Macintosh Applications.

What you say is true, but it takes a while to master TCL.  The trick is
to not force TCL to do something it was not designed to do.  In other
words, make your application fit TCL way of doing things and you'll be
a much happier camper (until you become more experienced in TCL).

|> Are there any books (besides the Symantec TCL Guide) that provide "Getting
|> Started" type information.

There's the code!  I'm serious about that one!!  This is how you find
out the deep dark secretes of TCL.

|> I'm also interested in people's opinions on TCL.  Is learning it worth the
|> investment in time?  How long does it take to become comfortable with the
|> library?

It all depends on the job you are trying to accomplish.  If your doing a
medium to small application TCL may be the ticket for you.  If your
doing something that's real industrial strength then MacApp might be
the way to go.  I have found it to be worth learning and useful as a
framework, but PowerPlant just might change my mind in the future when
I get a hold of it.

There is a news group dedicated to to TCL called comp.sys.mac.oop.tcl
and you might want to defer questions to that group.  Also there is an
ftp site for a bunch of TCL classes at ftp.brown.edu.

Hope this helps.

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Dent)
Date: 1 Mar 1994 17:36:10 +0800
Organization: DIALix Services, Perth, Western Australia

Darick

Depending on what you are doing with TCL, you may want to escape from some
of the hassles by using an interface editor/generator program.

Both AppMaker and Marksman generate excellent TCL code (immodest bit here:
I wrote the Marksman TCL templates). I believe Marksman is better value for
money and certainly the current version has better interface support,
including full color.

Marksman demos are available on most ftp sites that mirror info-mac or
umich. The code demos are posted separately from the editor demo, which
lets you do everything but save a prototype.

The TCL code demos should be on their way by now.

In general, my advice to TCL beginners is "relax and don't try to learn it
all". You can do an amazing amount with TCL without having to learn too much
about it's internals, until you need to change the standard behaviours.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241


---------------------------

>From [e-mail] (Eddy J. Gurney)
Subject: How would you write a text-based log window?
Date: Wed, 23 Feb 1994 23:39:46 GMT
Organization: Hewlett-Packard VCD

I'm wondering if anyone has any suggestions to implementing a simple,
fast, and effective read-only text-based log window. I have the need to
have a window open to which I would write various status messages while
the application runs. Since the this application could run for a lengthy
period of time, I'd like the older data to be discarded for newer data
when the buffer reaches some predetermined size.

Currently I'm using Eric Soldan's "TextEditControl" from Apple's
DTS.Lib, and it works fairly well. (If anyone's interested, it was
very simple to extract this complete TextEditControl from DTS.Lib to a
completely "self contained" module which can be included in a THINK C
application, giving you an editable text control in a window with no
effort on your part.) I'm just wondering if there is a better solution.
It should do all the normal TextEdit things like selecting text, scrolling
while selecting, vertical scrollbar (horizontal is not necessary in my
case), etc.

I'm just wondering if using TextEdit via Eric's TextEditControl is
"overkill" and adding too much overhead to something which could be much
simpler. (The slowest part right now is when the buffer fills up...
in that case I do a TESetSelect to select some number of bytes, call
TEDelete to remove them, TESetSelect to move to the end of the data and
then TEInsert to add the new text.)

Any ideas or suggestions appreciated...

Thanks,
Eddy

--
Eddy J. Gurney N8FPW   Hewlett-Packard Company, Vancouver (USA!) Division
[e-mail]                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 Feb 1994 17:04:04 -0800
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Eddy J. Gurney) writes:
>I'm wondering if anyone has any suggestions to implementing a simple,
>fast, and effective read-only text-based log window. I have the need to
>have a window open to which I would write various status messages while
>the application runs. Since the this application could run for a lengthy
>period of time, I'd like the older data to be discarded for newer data
>when the buffer reaches some predetermined size.

If you don't really need character level selection (ie line level selection
would suffice), use the list manager. I've wrote a dataviewer program
that display large amounts of text in a scrolling list and it supports
tab stops. My intent was to create a freeware document maker/viewer.
Using the list manager is easy and fun. Ldef's are easy to write just keep
the data out of the list manager.

Another program I wrote called more or less displays large amounts of text
by using drawtext. I intend to make both programs support PPC and or
AppleEvents so that programmers can pipe debugging output these programs
and have a easy to use log. No muss no fuss AEprintf/AEwriteln. :-)



Xavier


--
___________________________________________________________
Matthew Xavier Mora                    [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (WalrathW)
Date: 28 Feb 94 11:05:50 -0500
Organization: RFE/RL Inc.

In article <[e-mail]>
[e-mail] (Eddy J. Gurney) writes:

> I'm wondering if anyone has any suggestions to implementing a simple,
> fast, and effective read-only text-based log window. I have the need to
> have a window open to which I would write various status messages while
> the application runs. Since the this application could run for a lengthy
> period of time, I'd like the older data to be discarded for newer data
> when the buffer reaches some predetermined size.
[deleted]
> Any ideas or suggestions appreciated...
>
> Thanks,
> Eddy

I'm taking the advice suggested in a develop article several issues
back, and using the Terminal Manager for simple debugging info. I've
got a serial port capture application which only sends the data to
files, but I added support for piping it to a TM window as well, to see
what's supposed to end up in the files.

You might checkout DebugWindow library.  Here's some info from the
README:

   DebugWindow is a utility that mimics the Windows 3.x program of the
same name.
It allows you to easily print out display strings during the
development stages of
your program without any of the headaches normally associated with
built-in
"standard I/O" functions.

    DebugWindow's features:


  %  full "printf()" functionality for C programmers without any added
coding on
      your part

  %  will remember its location and size on the screen across sessions

  %  no more hassles of trying to incorporate Think C's "stdio" window
      in with your pure Toolbox code

  %  allows you to save any information that you've printed into its
window to a
      TeachText document

  %  callable from either Think C or Hypercard

(Debug Window is written by Keith Ledbetter)

It's available in the usual Mac archive sites.

cheers,
______o0o______
 Wayne Walrath
 RFE/RL Inc.

---------------------------

>From [e-mail] (P.A. Brooks-Johnson)
Subject: Reducing screen flicker in simple animation.
Date: Mon, 21 Feb 1994 13:17:13 GMT
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.



I'll make the apology first for this being a newbie question, but I'm in a bit of a time fix so I need some help. (and where better to look?)

A little background:
I'm writing a simple algorithm animator for the Mac (and other platforms .....) I'm just moving simple rectangles round the screen so there's no need for complex animation stuff. Based on a book by Mark Watson ( Portable GUI development in C++) which IMO ain't bad, but is a bit buggy, I've got redraw etc to work OK. The problem is the screen flicker, mainly due, I guess, to constantly erasing and redrawing the object which are moving.

My solution:
I propose to draw to an off screen grafPort then use copyBits to move the image from offScreen.portBits to screen.portBits.

The question:
Very simple.... is this right?? Is the reduction in flicker worth the bother or shall I just spend my precious (no not precious, just very limited!) time on something else? Is there a better way? I get the impression qd provides some explicit support for this kind of thing.....

Thanks for your help, I may even understand all this one day!!!


Peter

([e-mail])

+++++++++++++++++++++++++++

>From Michael Burks <[e-mail]>
Date: Mon, 21 Feb 1994 11:07:53 -0500
Organization: Fifth yr. senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 21-Feb-94 Reducing screen
flicker in .. by P.A. Brooks-Johnson@newc
> <How do I move rectangles around the screen without flicker deleted>
> My solution:
> I propose to draw to an off screen grafPort then use copyBits to move
the image
> from offScreen.portBits to screen.portBits.
>
> The question:
> Very simple.... is this right?? Is the reduction in flicker worth the
bother or
> shall I just spend my precious (no not precious, just very limited!)
time on som
> ething else? Is there a better way? I get the impression qd provides
some explic
> it support for this kind of thing.....
>
> Thanks for your help, I may even understand all this one day!!!
>
What you propose will work.  I would call it psuedo-double bufferring.
It's a common thing.  Whether you want to do it is a very subjective
question.

There are lots of other solutions.  If it's just rectangles, you could
easily keep track of what pixels have changed yourself (this extends to
polygons), and only update them.  You could also use color cycling
(animating colors).

Blaine.

+++++++++++++++++++++++++++

>From Sander C. Temme <[e-mail]>
Date: 22 Feb 94 14:00:18 +0100
Organization: University of Amsterdam



In article <[e-mail]> P.A. Brooks-Johnson,
[e-mail] writes:
>The question:
>Very simple.... is this right?? Is the reduction in flicker worth
the bother or
>shall I just spend my precious (no not precious, just very
limited!) time on
>something else? Is there a better way? I get the impression qd
provides some
>explicit support for this kind of thing.....
The easiest way to do this is documented in the acclaimed book 'How
to Write Macintosh Software' by Scott Knaster as 'Smooth Animation
for the Rest of Us':

You can synchronize your drawing with the vertical retrace (i.e.
when the electron beam moves from lower right corner to upper left
corner of the screen) so you change the video RAM when no drawing is
going on. When the Mac hits vertical retrace, it generates an
interrupt. One of the things this interrupt does is increase the
TickCount global Variable. So, what the rest of us do to get smooth
animation is let our program sit in a tight loop waiting for
TickCount to change, and when it does, draw like heck.
Only, this method dates from way back when multiple screens and
CQuickDraw weren't an issue. You'll have to see whether it still
works. When it did (when I toyed around with simple animation on a
Plus), it gave nice results for all its simplicity.

>
>Thanks for your help, I may even understand all this one day!!!
(-: (-:

Sander


Sander C. Temme, University of Amsterdam, Holland [e-mail]
-------------------------------------------------------------------
'Denkt U werkelijk dat wij zo gek zijn om voor een weddenschap naar
Zuid-Afrika te vliegen?'
                         -- Bob Evers

+++++++++++++++++++++++++++

>From [e-mail] (M. Scott Smith)
Date: Tue, 22 Feb 1994 17:22:35 GMT
Organization: The Great Beyond

In article <[e-mail]> Sander C. Temme <[e-mail]> writes:
>
>You can synchronize your drawing with the vertical retrace (i.e.
>when the electron beam moves from lower right corner to upper left
>corner of the screen) so you change the video RAM when no drawing is
>going on. When the Mac hits vertical retrace, it generates an
>interrupt. One of the things this interrupt does is increase the
>TickCount global Variable. So, what the rest of us do to get smooth
>animation is let our program sit in a tight loop waiting for
>TickCount to change, and when it does, draw like heck.
>Only, this method dates from way back when multiple screens and
>CQuickDraw weren't an issue. You'll have to see whether it still
>works. When it did (when I toyed around with simple animation on a
>Plus), it gave nice results for all its simplicity.
>

   Unfortunately this method doesn't work anymore, at least not for color
monitors.

   The global variable "TickCount" has traditionally been updated every
1/60 of a second -- which was nicely in sync with the refresh rate on the
old black and white Mac monitors.

   On color monitors, the refresh rate is rarely 60 hz., and even if it
is, there's no real guarantee that it's going to be perfectly in sync
with TickCount.

   What you need to do, then, is "sync up" with whatever monitor happens
to be attached to the Mac.  How do you do this?  Well, luckily there's
sample code floating around to do just this.  I know Mike Kelly has
written some (I haven't seen him around much; must be busy with his
newfound success!  :), and I believe there's some code in the Mac
programming FAQ which you can download from sumex-aim.stanford.edu
(among places).  Several other people have written sample code to do
it.  (I'm sure Jon Witte has.)  It's not particularly friendly code,
and most implementations I've seen use some assembly language.

   Just synching to the monitor isn't a full solution, however.  For
this method to work as expected, you need to be sure that you can get
all your drawing done in less than one screen refresh -- typically
somewhere around 1/60th -> 1/70th of a second.  If it takes 1.5 screen
updates to do your drawing, you're not necessarily gaining much by
synching.  (I haven't done much testing so I can't say if you're better
off synching than not in situations like this.  In any case, synching
will almost always have the effect of slowing down your animation -- after
all, you'll be spending time waiting around for that electron gun to get
to the top of the screen.  I wrote a screen saver that simply animates
a sphere bouncing around the screen.  I wrote directly to video RAM,
and used a number of other tricks to make it as quick as possible.  The
result was mind-numbingly fast animation -- the ball ricocheted (sp?) back
and forth faster than the eye could see.  When I added synching, the ball
moved pretty slowly -- very smoothly, yes, but it was now animating one
frame in the time it was doing 40 or more before.  So, in some cases,
you might want that "non-smooth" effect which you get with high-frame-rate
animation.  But I digress..)

   The method you use to draw to the screen will greatly affect how much
time it takes.  I didn't catch your original message, so I'm not sure
if you're aware that "offscreen buffers" are the best way to achieve
smooth animation.  If you're not familiar with their definition or use,
I'd be happy to explain them to you.

   You generally do all of your drawing "offscreen", and copy your picture
to the screen (via CopyBits or writing directly to the video RAM or
directly into a PixMap, etc.) only once it's completely ready.  It's
much quicker to write offscreen and the user doesn't see the individual
pieces of the picture being painted, etc., which can look really bad if
done on-screen.

   Well, this has been somewhat of a cluttered message but I hope you
got something out of it.  Check out the programming FAQ's -- they should
have information on "monitor-independent" synching, which is one step
towards smooth animation.  And if you're not familiar with offscreen
drawing, you'll want to look into GWorlds, which are probably the most
painless way to do it.  (Plus you'll want to look around for some theory
on how to best use offscreen environments -- I've seen lots of different
methods, and I suppose which one you choose depends on your specific
application.)

   If you're going to be doing intensive-graphics-therapy in your game/
program/whatever, you might wish to look into (gasp!) drawing directly to
the screen.  CopyBits is an incredibly versatile tool, but that versatility
adds some overhead in many situations; it may not be the best choice
for arcade-style animation.

   On that note, here's a question for those of you in the know -- I haven't
had a chance to play around with the PPC much; is direct-screen drawing (if
done properly) still functional with the PowerPC's?

   I've constructed a C++ "direct-screen" library which takes a lot of
the pain out of direct screen drawing, I might get around to polishing
it up and releasing it some day.

   Good luck!  Executing animation properly can make a big difference
in the appearance of your program.  It's worth it to spend the time
researching -- there's a lot to learn.

Later,

M. Scott Smith


+++++++++++++++++++++++++++

>From [e-mail] (John Werner)
Date: Tue, 22 Feb 1994 16:58:02 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, Sander C. Temme
<[e-mail]> wrote:

> You can synchronize your drawing with the vertical retrace
> ....
> interrupt. One of the things this interrupt does is increase the
> TickCount global Variable. So, what the rest of us do to get smooth
> animation is let our program sit in a tight loop waiting for
> TickCount to change

This ceased to be true in 1987 with the advent of the Mac II.  On machines
with Color Quickdraw, the global TickCount counter is not necessarily tied
to the refresh rate on any particular monitor.  TickCount is increment 60
times a second, while the refresh rate on most monitors these days is in
the 65-75 Hz range.

There's still a way to get what you want, however.  You need to figure out
which screen your window is (mostly) on, by looping through all the screen
devices with routines like GetNextDevice.  Then you find the slot number
for that device and install your VBL task with SlotVInstall.

I have a TCL class that does all this in the TCL archives at brown.edu.
You won't be able to use the code unless you're writing a TCL app, but it
might help you get started.  The class is called CVblSync or some such
thing.

--
John Werner                           [e-mail]
Taligent, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Arsenault)
Date: Tue, 22 Feb 1994 12:58:35 -0500
Organization: Motorola Codex

In article <[e-mail]>, [e-mail]
(P.A. Brooks-Johnson) wrote:

> The problem is the screen flicker, mainly due, I guess, to constantly erasing and redrawing the object which are moving.
>
> My solution:
> I propose to draw to an off screen grafPort then use copyBits to move the image from offScreen.portBits to screen.portBits.

This is great if you have a lot of internal animation to deal with (like a
figure walking while moving across the screen).  It may not be necessary if
you're doing something simple like drawing solid color rects on the screen.
There are several possible ways to reduce flickering animation, and they
may be combined:

 - use the VBL to sync so you draw only during vertical retrace.  This
gives you the best results. You can loop and wait for the retrace by
watching ticks. Try to write your function so you can handle events etc
while waiting for vertical retrace to come around. The trick here is arrive
at the draw function with very few ticks to waste.  You can also install a
VBL task to perform the drawing (just don't allow Memory Mgr memory moves
to occur during the interrupt) Make sure you switch the saved screen port
in before drawing. Provided you're just doing a minimal amount of drawing
this will work nicely.
There is a couple of things you should be aware of when using VBL sync for
drawing - in general it works, but on various monitors (which use different
refresh rates) it's not always flicker-free.  Getting good results in that
situation is a whole book in itself.

- queue up all your drawing objects (prepare a draw list) ahead of time.
When you get the VBL sync all you do is draw - fast.  This means you don't
combine calculations with drawing time. Do all your calculations while the
user is looking at the last image.

 - calculate minimum update rects for each moving object on screen. Just
determine the deltas between where the old image was drawn and where the
new one needs to be, then draw that. For example if I have a rectangle
moving horizontally across the screen, all I have to erase is the
difference of the move, and draw the move difference on the other side.
(Erase a small rectangle on one side and draw a small rectangle on the
other)  This works best when you have solid colors to animate, and the size
and number of rectangles justifies the overhead for the calls and
calculations. This technique is great for flight simulators where you have
to do polygon manipulation and provide really fast frame rates.

- buffered offscreen minimal update. When you have a number of different
objects moving around the screen and you'll be spending more time either
trying to grab the video card (NuBus) or trying to restore a background,
create an offscreen port and do your drawing there. The area that you want
to draw to the screen is the union of the previously drawn rect and the
union of all the new rects to draw. Create the drawing list, restore
background or previous,  draw all the rects over this , then wait for VBL,
then CopyBits the offscreen image (just the minimal update union rect) to
the screen.

- color cycle animation can be really quick, but animating colors are best
used inside some other image which is copyed to the screen via one of the
methods suggested above.
I tried to do a simple scrolling effect using color cycling behind moving
images, it looked okay, but called for more color management overhead than
the effect was  worth.

Hope this helps,
Chris

--
#include <UsualLegalDisclaimers.h>

+++++++++++++++++++++++++++

>From [e-mail] (Dietmar Heidrich)
Date: 28 Feb 1994 14:54:15 GMT
Organization: University of Karlsruhe, FRG


As a visitor to this group, I'd like to know if there is
double-buffering for the Mac, meaning you can draw in the
background and display a foreground screen and exchange both
at vertical blank.  This is the best technique for providing
smooth animation.

Now: Is this possible with the Mac toolbox ?  I could not find
anything about it in the Inside MacIntosh books.

Personal mail preferred, as I don't read this group.  Of course,
you may also reply in public and PM.

Thanks.



--
Dietmar Heidrich, Universitaet Karlsruhe, Germany


"Die Hoffnung auf den Tod ist das einzige, was mich am Leben erhaelt."

---------------------------

>From [e-mail] (Vincent Partington)
Subject: What to say when the appropiate Gestalts aren't there?
Date: 23 Feb 1994 11:11:23 GMT
Organization: FWI, University of Amsterdam

Hi!

Apple advises developers to check the Gestalt-selectors to determine of
certain System features are available instead of checking for System version.
In my Sys7-only app (supporting Sys6 is just too cumbersome because about half
of my systemcalls are Sys7-ones in my not-too-big app) I first check for
the availability of Gestalt and then check all kinds of Gestalt-selectors
for stuff like FSSpec-calls, new Standard File calls, Alias Manager, etc, etc.

When I don't find those features I will have to let the user know and will have
to pop up an alert telling him to upgrade or die. What should this alert say?
Saying "You'll have to upgrade to Sys7 or later" is contradictory to checking
Gestalt because Sys8 may not have the FSSpec-calls (small chance).
Saying "You'll have to upgrade to System 7.1.6" (which I use) would be
weird if Sys8 can do everything Sys7.1.6 can.
Saying "Get a system thet has the Gestalt-trap, returns a 1 in bits 0 and 1 of
the return from Gestalt-selector for the file system, returns 1 in bit 0 of
the returnvalue from Gestalt-selector...etc...etc." would be rather
user-unfriendly.

Any comment?

Vincent.
--
BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA   Internet : [e-mail]
BLABLA 68040 Power! ABLABLABLABLABLABLABLABLA              [e-mail]
BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA   FidoNet  : 2:281/202.15
BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA   NeST     : 90:500/202.15

+++++++++++++++++++++++++++

>From [e-mail] (Howie Rafal)
Date: 23 Feb 1994 19:31:09 GMT
Organization: BBN, Inc

In article <2kfdkr$[e-mail]>, [e-mail] (Vincent
Partington) wrote:
> When I don't find those features I will have to let the user know and will
> have

You could first check what version of the system is running and give the
version  message if it applies.  Otherwise, If the system version is 7.x or
greater, explain that certain necessary features are missing from the
Macintosh and then give a list box of the missing managers (if they care).
This would be better than listing just one manager is missing.  They could
then upgrade as needed.

+++++++++++++++++++++++++++

>From Pascal_Haakmat
Date: Wed, 23 Feb 94 20:08:28 +0100
Organization: (none)

 VP> What should this alert say?

Well, be honest with the user, tell him what's going on ...

Like: "Your system does not support the required FSSpec File Manager
calls."
If Gestalt returns a system version < 7 you might add "You should
upgrade to System 7."



    Pascal.

--- Obolus 1.0.2
 * Origin:  go on upstairs with your sweet little wishes  (2:281/202.13)

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Fri, 25 Feb 1994 18:20:07 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Pascal_Haakmat writes:
> VP> What should this alert say?
>Well, be honest with the user, tell him what's going on ...
>Like: "Your system does not support the required FSSpec File Manager
>calls."If Gestalt returns a system version < 7 you might add "You should
>upgrade to System 7."
Or, perhaps, "_MakeFSSpec is not available." :->  Better yet, explain in
details that are useful to the typical user:
    "<This Program> requires System 7 or later."
or
    "<This program> requires a floating point unit."
or
    "<This program> requires color support (Mac II or better)."
If you really think the user wants to know which particular feature
isn't available, encode it as a little digit somewhere, and put it in
the documentation.  Since one can't get the revised file manager
*without* System 7, telling them they need it won't really help them
solve their problem.
--
-Bill Hofmann                    [e-mail]
 Fresh Software and Instructional Design    [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 26 Feb 1994 22:34:34 GMT
Organization: cellular

[e-mail] (Bill Hofmann) writes:

>the documentation.  Since one can't get the revised file manager
>*without* System 7, telling them they need it won't really help them
>solve their problem.

Untrue. One can get it with QuickTime. I'm not sure if the Gestalt
selector gets installed, though. I believe you have to test for
QuickTime *or* the new File Manager calls, and then use the subset of
the new File Manager calls which are in QuickTime.

This is a thorny problem, and in general I think you are right to
suggest that the message talk about System 7 instead of the new File
Manager calls, but in this particular case, there is a solution other
than System 7. It's hard to know what to put in the message.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Rene G.A. Ros)
Date: Sun, 27 Feb 1994 09:17:37 GMT
Organization: VU Biology, Amsterdam, The Netherlands

[e-mail] (Pete Gontier) writes:
: [e-mail] (Bill Hofmann) writes:
:
: >the documentation.  Since one can't get the revised file manager
: >*without* System 7, telling them they need it won't really help them
: >solve their problem.
:
: Untrue. One can get it with QuickTime. I'm not sure if the Gestalt
: selector gets installed, though. I believe you have to test for
: QuickTime *or* the new File Manager calls, and then use the subset of
: the new File Manager calls which are in QuickTime.

>From my Suppl. Gestalt Selectors list:

QuickTime
---------
If you install QuickTime under System 6, a major portion of the Alias
Manager and FSSpec support is also added. But, QT doesn't implement the
Gestalt selectors because the implementation is not complete. You must
check for either Alias Mgr or QuickTime. (Michael Hecht)
If QuickTime is present, assume you have an Alias Manager, subject to some
limitations (NewAliasMinimalFromFullPath not present). Nearly all the
FSSpec calls are available (except FSpExchangeFiles) in System 6 when
QuickTime is installed. See for more information Technical Note
M.QT.MovieTB.Q&As (QT 510).


Regards,
Rene
--

--------------------------------------------------------------------------------
  Rene G.A. Ros                                      Amsterdam, The Nederlands
  [e-mail]         [e-mail]          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Vincent Partington)
Date: 27 Feb 1994 15:21:01 GMT
Organization: FWI, University of Amsterdam

[e-mail] (Rene G.A. Ros) writes:

>QuickTime
>---------
>If you install QuickTime under System 6, a major portion of the Alias
>Manager and FSSpec support is also added. But, QT doesn't implement the
>Gestalt selectors because the implementation is not complete. You must
>check for either Alias Mgr or QuickTime. (Michael Hecht)
>If QuickTime is present, assume you have an Alias Manager, subject to some
>limitations (NewAliasMinimalFromFullPath not present). Nearly all the
>FSSpec calls are available (except FSpExchangeFiles) in System 6 when
>QuickTime is installed. See for more information Technical Note
>M.QT.MovieTB.Q&As (QT 510).

What a shame, no FSpExchangeFiles! That's the one I really like about the
new calls. Well, I think assuming the FSSpec calls are then when QuickTime is,
is weird anyway, so I wouldn't have checked one way or another.
I really like a lot of other things about Sys7 too: Alias Manager, Find Folder,
Popup CDEF, Apple Events, Notification manager, Temporary Memory (OK,
MultiFinder has it too, but not "real" temp mem), CustomGetFile, so supporting
Sys6 would be a real drag.

Vincent.
--
VI is better than Emacs.      | Let's     | Internet : [e-mail]
MacOS is better than Windows. | start the |            [e-mail]
Unix is better than VMS.      | religious | FidoNet  : 2:281/202.15
Eiffel is better than C++.    | war!!     | NeST     : 90:500/202.15

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 28 Feb 94 16:30:50 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Pete Gontier) writes:
> [e-mail] (Bill Hofmann) writes:
>
>>the documentation.  Since one can't get the revised file manager
>>*without* System 7, telling them they need it won't really help them
>>solve their problem.
>
> Untrue. One can get it with QuickTime. I'm not sure if the Gestalt
> selector gets installed, though. I believe you have to test for
> QuickTime *or* the new File Manager calls, and then use the subset of
> the new File Manager calls which are in QuickTime.
>
> This is a thorny problem, and in general I think you are right to
> suggest that the message talk about System 7 instead of the new File
> Manager calls, but in this particular case, there is a solution other
> than System 7. It's hard to know what to put in the message.

My ad hoc, informal guideline, which I just thought up off the top of my
head, is "explain just the simplest case". If you need the new File Manager
calls, then I personally would just say "I need System 7 or later". If in
fact the program can be made to work under 6.0.7 with QuickTime installed,
then you can explain that in the documentation somewhere, or as an answer
to a tech support question. Don't try to burden your compatibility messages
with all the possible situations. It's less confusing that way.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
"Classical Paintings: DaVinci, Degauss, Rembrant, Van Gogh and more! View
the works of history's finest artists."  -- ad quoted in PC Magazine

+++++++++++++++++++++++++++

>From [e-mail] (Alan Akins)
Date: 28 Feb 1994 08:24:00 -0800
Organization: The uncharted backwaters of the unfashionable end of the                  Western Spiral arm of the Galaxy.

In article <[e-mail]>,
Rene G.A. Ros <[e-mail]> wrote:

>If you install QuickTime under System 6, a major portion of the Alias
>Manager and FSSpec support is also added. But, QT doesn't implement the
>Gestalt selectors because the implementation is not complete. You must
>check for either Alias Mgr or QuickTime. (Michael Hecht)
>If QuickTime is present, assume you have an Alias Manager, subject to some
>limitations (NewAliasMinimalFromFullPath not present). Nearly all the
>FSSpec calls are available (except FSpExchangeFiles) in System 6 when
>QuickTime is installed. See for more information Technical Note
>M.QT.MovieTB.Q&As (QT 510).

Is this still true of QuickTime 2.0? Have they "completed" the implementation?

/Alan\
--
*      "Evan's been doing parallel       |    Alan Akins                      *
*           processing for so long...    |    [e-mail]            *
*                 he's beside himself."  |    University of Oregon            *
*                        - Me            |    Department of Computer Science  *

+++++++++++++++++++++++++++

>From [e-mail] (Rene Ros)
Date: Mon, 28 Feb 1994 17:52:43 GMT
Organization: NIKHEFK

[e-mail] (Alan Akins) writes:
: In article <[e-mail]>,
: Rene G.A. Ros <[e-mail]> wrote:
:
: >If you install QuickTime under System 6, a major portion of the Alias
: >Manager and FSSpec support is also added. But, QT doesn't implement the
: >Gestalt selectors because the implementation is not complete. You must
: >check for either Alias Mgr or QuickTime. (Michael Hecht)
: >If QuickTime is present, assume you have an Alias Manager, subject to some
: >limitations (NewAliasMinimalFromFullPath not present). Nearly all the
: >FSSpec calls are available (except FSpExchangeFiles) in System 6 when
: >QuickTime is installed. See for more information Technical Note
: >M.QT.MovieTB.Q&As (QT 510).
:
: Is this still true of QuickTime 2.0? Have they "completed" the implementation?

Don't shoot the messenger! :-)
I have no idea if QT 2.0 implements the Alias Mgr and FSSpec calls. Would be
nice, the gestalt selectors should then be installed also. So, simple
check for the selectors now and perhaps you will support System 6/QT in the
future?
I myself use two procedures to determine if the Alias Mgr is partially or
fully installed. Where I use the 'qtim' selector to see if it is partiallu
installed.
If someone has anymore info about this regarding QT 2.0 I would like to
know. Or has someone the email address of 'the powers that be' at Apple? :-)
The prese release didn't say anything about it, which doesn't surprise me.

Rene


+++++++++++++++++++++++++++

>From [e-mail] (monsieur HAINEUX)
Date: Tue, 1 Mar 1994 00:45:14 GMT
Organization: /usr/local/lib/rn/organization

The problem with configuration problems is that most users will need
more explanation than you can fit in a dialog box. Even if you can fit
the whole explanation in a dialog box, most users will forget what the
dialog says as soon as it's gone, or see all those words and call Tech
Support before thinking anything through.

The trick is to explain the situation in a pithy, easily-memorable way
in the dialog, then explicitly point to the documentation for further
explanation.

For example:

(STOP)    Missing resources: <MyApp> cannot launch.

    Some necessary resources are not present in your
    Macintosh. Please check the "Configuration Requirements"
    section in your <MyApp> manual.

    ErrNo: <12345>            (Quit)

(STOP)    No Color Available: <MyApp> cannot launch.

    <MyApp> cannot find a color screen connected to your
    Macintosh. Please chek the "Configuration Requirements"
    section in your <MyApp> Manual.

    ErrNo: <12347)            (Quit)

It's up to you to provide the documentation that explains the whole
deal. For example, the documentation might read:

CONFIGURATION REQUIREMENTS
    <MyApp> requires a Mac Minus or better to run, System 7.0 or
    newer, 4 bit color, 437 MB of RAM memory, and 34K of disk
    space (minimum). We recommend for best performance, however, that
    you turn off virtual memory and make sure your entire hard
    disk is blank.

    If your Mac doesn't have enough memory, throw it away and buy
    a new one. If it has the required memory, but <MyApp> still
    won't launch, try turning off memory-using INITs, quitting
    other apps, and waving a dead chicken over it.

NOTE:
    Technically advanced users may be able to run <MyApp> by
    installing GreedManager 3.17 and FondleMonger 1.0d127c23 on
    System 6.x. If you would like support on how to set up this
    configuration, kindly submit your request on the back of a
    hundred-dollar bill to:...

Later, in the appendix on Error Numbers, you have your choice. If you
want to reserve a whole suite of errnos for launch fail, you can have
separate messages in the index:

ERNO    Explanation
12345    GreedManager is missing. See "REQUIREMENTS" section of manual.
12346    FondleMonger is missing. See "REQUIREMENTS" section of manual.

Or you can have just one:

ERRNO    Explanation
12345    Mac does not meet minimum configuration requirements. See
    "REQUIREMENTS" section of manual.

bill coderre

---------------------------

>From Joshua Joseph Marks <[e-mail]>
Subject: small snag
Date: Mon, 28 Feb 1994 18:43:17 -0500
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

I have this one problem that is probably linked to not being familiar
with writing code on the MAcintosh, or it could be just a big oversite.

I have a structure defined as:
struct branch
{
    short type,xi,yi;
}


when running through the following code I get a BUS ERROR

struct element *Init_Branch (short x, short y, float direction, short length)
{
    struct element *new_element;

    new_element = (struct element*) malloc (sizeof (struct element));
    if (new_element == NIL) ExitToShell();

    new_element->xi = x_start;
    new_element->yi = y_start;
    new_element->type = BRANCH_LENGTH; ....


The problem is of course the malloc, which screws everything up when it
gets two lines later.  I cant seem to trace where the problem is.  I
have the struct defined in a seperate header file that is included at
the top, and I have a the segments placed so that 2 contains ANSI and
the main portion, and 3 contains MacTraps and all suboordinate
proceddures.  Does the way you segment things matter?  Does ANSI have to
be somewhere.  Thanks for any suggestions and thanks doubly for
solutions.
                                                            Josh


+++++++++++++++++++++++++++

>From [e-mail] (M. Scott Smith)
Date: Tue, 1 Mar 1994 01:19:14 GMT
Organization: The Great Beyond

In article <[e-mail]> Joshua Joseph Marks <[e-mail]> writes:
>I have this one problem that is probably linked to not being familiar
>with writing code on the MAcintosh, or it could be just a big oversite.
>
> (problem described)
>
>The problem is of course the malloc, which screws everything up when it
>gets two lines later.  I cant seem to trace where the problem is.  I
>have the struct defined in a seperate header file that is included at
>the top, and I have a the segments placed so that 2 contains ANSI and
>the main portion, and 3 contains MacTraps and all suboordinate
>proceddures.  Does the way you segment things matter?  Does ANSI have to
>be somewhere.  Thanks for any suggestions and thanks doubly for
>solutions.
>                                                            Josh
>

Josh,

   I'm going to take a very wild guess of what *might* be your problem,
without studying your code too much.

   If you're not including <stdlib.h>, MAKE SURE you do.  At the start of
your program, do this:

#include <stdlib.h>

   If you're not doing this, then I'd suspect that's your problem, because
I've had the same problem in the past.  If I recall correctly, there's
a couple different versions of malloc out there, and unless you include
stdlib.h you're not getting the right one.  (I forget the exact
reasoning behind this.)  The standard libraries reference for Think C
(as well as Think Reference 2.0 database module included w/Think C v6.0x)
mentions that "if you have any problems with malloc(), make sure you
#included stdlib.h in your source file.  I believe it.

   So definitely do that if you aren't.  If you are, well, umm, uhh..
Sorry to have gotten your hopes up.

   But to answer some of your questions, no, it doesn't matter how you
segment things.  Segments are transparent to the programmer, although
if you know what you're doing you can fool around with placement of
files in the segment to speed up programs.  (For example, code segments
are loaded into memory one at a time.  You can "pre-load" segments that
contain frequently-used code.  You might toss code that prints a document
in a separate code segment that you don't preload, since users don't
print documents that much.  When the user does print the document, there
might be a pause as that segment is loaded from disk.)  BUT, all of this
is transparent to you.  It's all memory management magic.

   You'll also benefit from learning about NewPtr and NewHandle, which are
the "cool" ways of allocating memory on the Macintosh.  Lots of people have
problems with the ANSI routines.  But few people use them.  Most people
use the Mac-specific routines, and few people have problems with them.
(Huh?)  :)

   Don't take too much faith in this, but this is how you can allocate
structures using the Mac's NewPtr routine:  (borrowed partially from Think
Ref)

struct MyStruct
{
  short  tall;
}

struct MyStruct *myStructPtr;

myStructPtr = (struct myStruct *)NewPtr(sizeof(MyStruct));

then you can do..

x = myStructPtr->tall;

   And you'll eventually probably want to use Handles, but those can be
tricky and I won't go into them now.

Good luck!  (And I hope the <stdlib.h> is all you need..)

Scott

---
M. Scott Smith    ([e-mail] || [e-mail])

   Macintosh developer. Ski bum. Student.  Eater of Cadbury Creme Eggs.


---------------------------

End of C.S.M.P. Digest
**********************